In order to establish communications over a network it is necessary to establish a session between the parties. Various protocols exist to accomplish this goal, including SIP, which is the Internet Engineering Task Force (IETF) standard for multimedia conferencing over IP, and which is defined in IETF RFC 3261, the contents of which are incorporated herein by reference.
The main entities in SIP are the User Agent (UA), the SIP Proxy Server (PS) the SIP Redirect Server (RS), and the Registrar. SIP is a client/server architecture in which the UA can act as either a user agent client or UAC (in the case that it is initiating a session) or a user agent server or UAS (in the case where it is responding to a request to initiate a session).
Each user has a SIP address, or more correctly, a SIP Uniform Resource Indicator (URI) in the form sip:user@domain.com or sips:user@domain.com (where sips: identifies the URI as an addressee for a secure call). This SIP address or URI (the terms being used interchangeably herein) is used in SIP requests to establish a call to that user. Because one of the intentions is that SIP should provide mobility to users, a user may log onto a network from any one of a number of locations, and register with the Registrar. The Registrar then notes the network address (IP address) of the user's current location.
When one attempts to establish a session with a user, a request message (of the type INVITE) is sent across the network via a series of proxy and redirect servers. The proxy servers forward on the message to the user (if the proxy server knows the user's location) or to the next server, which may itself be a proxy server or a redirect server. Redirect servers receiving a request will consult a location server which in turn has access to the Registrar server information. Based on the path (or network location) information available to the location server, the redirect server will return the request to the sender with the path information, and the sender (e.g. the previous proxy server in the chain) will re-send the request to the indicated location.
A request message will typically traverse multiple hops before arriving at the intended addressee's UA. This characteristic of the conventional SIP operation mechanism imposes significant processing overheads on all of the servers involved. The main reason for this is that as the request is contained in IP packet format, but the SIP “to:” URI (e.g. “send to: sip:user@domain.com”) is an ASCII string in a UDP datagram, the SIP address must be processed through the IP stack to the application layer to determine the address. With multiple SIP requests travelling through any node of the network, the processing overheads throughout the IP stack and in particular at the application layer, are high.
In the context of contact centres (such as call centres or multimedia contact centres), considerable importance is placed on allowing a networked contact centre to offload incoming contacts seamlessly to another contact centre. This might be done, for example, with calls which are in a particular language if the contact centre receiving the calls does not have the resources to efficiently handle calls in that language. It might also be done where all agents at the contact centre are busy. In such cases the contact centre might, either as a rule or while the conditions preventing efficient handling remain in place, transfer such calls to a partner contact centre.
If a SIP server or gateway associated with a contact centre transfers a SIP-based contact to another network location, SIP request is passed through the IP stack to the application layer and a SIP REFER message (similar to the initial INVITE message) is created and sent back to the source via the stack. The REFER message replaces the “to:” SIP address with a “refer to:” field including the SIP address of the new network location, and adds a “referred by:” field containing the SIP address of the referring user. This imposes high processing overheads if all SIP request messages are to be referred to another location.